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Abstract 


This document briefly introduces the existing mechanisms that could 
be utilized for IPv6 site renumbering and tries to cover most of the 
explicit issues and requirements associated with IPv6 renumbering. 
The content is mainly a gap analysis that provides a basis for future 
works to identify and develop solutions or to stimulate such 
development as appropriate. The gap analysis is organized by the 
main steps of a renumbering process. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7010. 
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Les 


Introduction 


As introduced in [RFC5887], renumbering, especially for medium to 
large sites and networks, is currently viewed as expensive and 
painful. This error-prone process is avoided by network managers as 
much as possible. If IPv6 site renumbering continues to be 
considered difficult, network managers will turn to Provider 
Independent (PI) addressing for IPv6 as an attempt to minimize the 
need for future renumbering. However, widespread use of PI 
addressing may create very serious BGP4 scaling problems [RFC4984]. 
It is thus desirable to develop tools and practices that make 
renumbering a simpler process and reduces demand for IPv6 PI space. 


Building upon the IPv6 enterprise renumbering scenarios described in 
[RFC6879], this document performs a gap analysis to provide a basis 
for future work to identify and develop solutions or to stimulate 
such development as appropriate. The gap analysis is organized 
according to the main steps of a renumbering process, which includes 
prefix management, node address (re)configuration, and updates to 
address-relevant entries in various devices such as firewalls, 
routers and servers, etc. Renumbering event management is presented 
independently from the steps of a renumbering process in order to 
identify some operational and administrative gaps in renumbering. 


This document starts from existing work in [RFC5887] and [RFC4192]. 
It further analyzes and identifies the valuable and solvable issues, 
digs out of some undiscovered gaps, and gives some solution 
suggestions. This document considers the make-before-break approach 
as a premise for the gap analysis, so readers should be familiar with 
[RFC4192]. 


Renumbering nodes with static addresses has a particular set of 
problems, thus discussion of that space has been covered in a related 
document [RFC6866]. 


This document does not cover the unplanned emergency renumbering 
Cases. 


Overall Requirements for Renumbering 


This section introduces the overall goals of a renumbering event. In 
general, we need to leverage renumbering automation to avoid human 
intervention as much as possible at a reasonable cost. Some existing 
mechanisms already provide useful capabilities. 


The automation can be divided into four aspects as follows. 
(Detailed analysis of the four aspects is presented respectively in 
Sections 4 through 7.) 
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Sel. 


o Prefix delegation and delivery should be automatic and accurate in 
aggregation and coordination. 


o Address reconfiguration should be automatically achieved through 
standard protocols with minimum human intervention. 


o Address-relevant entry updates should be performed together and 
without error. 


o Renumbering event management is needed to provide the functions of 
renumbering notification, synchronization, and monitoring. 


Besides automation, session survivability is another important issue 
during renumbering since application outage is one of the most 
obvious impacts that make renumbering painful and expensive. Session 
survivability is a fundamental issue that cannot be solved within a 
renumbering context only. However, the [RFC4192] make-before-break 
approach, which uses the address lifetime mechanisms in IPv6 
Stateless Address Autoconfiguration (SLAAC) and Dynamic Host 
Configuration Protocol for IPv6 (DHCPv6), allows for a smooth 
transition mechanism from old to new prefixes. In most cases, since 
we can set the transition period to be long enough to cover the 
ongoing sessions, we consider this mechanism sufficient to avoid 
broken sessions in IPv6 site renumbering. (Please note that if 
multiple addresses are running on hosts simultaneously, the address 
selection [RFC6724] needs to be carefully handled.) 


Existing Components for IPv6 Renumbering 


Since renumbering is not a new issue, some protocols and mechanisms 
have already been utilized for this purpose. There are also some 
dedicated protocols and mechanisms that have been developed for 
renumbering. This section briefly reviews these existing protocols 
and mechanisms to provide a basis for the gap analysis. 


Relevant Protocols and Mechanisms 


o Router Advertisement (RA) messages, defined in [RFC4861], are used 
to deprecate prefixes that are old or announce prefixes that are 


new, and to advertise the availability of an upstream router. In 
renumbering, RA is one of the basic mechanisms for host 
configuration. 


o When renumbering a host, SLAAC [RFC4862] may be used for address 


configuration with the new prefix(es). Hosts receive RA messages 
that contain a routable prefix(es) and the address(es) of the 
default router(s); then hosts can generate an IPv6 address(es) by 
themselves. 
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Hosts that are configured through DHCPv6 [RFC3315] obtain new 
addresses through the renewal process or when they receive the 
reconfiguration messages initiated by the DHCPv6 servers. 


DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated 
delegation of IPv6 prefixes using the DHCPv6. 


[RFC2894] defines standard ICMPv6 messages for router renumbering. 
This is a dedicated protocol for renumbering, but we are not aware 


of real network deployment. 


Management Tools 


Some renumbering operations could be automatically processed by 
management tools in order to make the renumbering process more 
efficient and accurate. The tools may be designed specifically for 
renumbering, or common tools could be utilized for some of the 
renumbering operations. 


Following are examples of such tools: 


o 


Liu, 


IP address management (IPAM) tools. There are both commercial and 
open-source solutions. IPAM tools are used to manage IP address 
plans and usually integrate the DHCPv6 and DNS services together 
as a whole solution. Many mature commercial tools can support 
management operations, but normally they do not have dedicated 
renumbering functions. However, the integrated DNS/DHCPv6 
Services and address management function can obviously facilitate 
the renumbering process. 


Third-party tools. Some organizations use third-party tools to 
push configuration to devices. This is sometimes used as a 
supplement to vendor-specific solutions. A representative of such 
a third-party tool is [CFENGINE]. 


Macros. [LEROY] proposed a mechanism of macros to automatically 
update the address-relevant entries/configurations inside the DNS, 
firewall, etc. The macros can be delivered through the SOAP 
protocol from a network management server to the managed devices. 


Asset management tools/systems. These tools may provide the 
ability to manage configuration files in devices so that it is 
convenient to update the address-relevant configuration in these 
devices. 
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3.3. Procedures and Policies 


o [RFCA4192] proposed a procedure for renumbering an IPv6 network 
without a flag day. The document includes a set of operational 
suggestions that can be followed step by step by network 
administrators. It should be noted that the administrators need 
to carefully deal with the address selection issue, while the old 
and new prefixes are both available during the overlapping period 
as described in the procedures in [RFC4192]. The address 
selection policies might need to be updated after renumbering, so 
the administrator could leverage the address-selection-policy 
distribution mechanism as described in [6MAN-ADDR-OPT]. 


o [RFC6879] analyzes the enterprise renumbering events and makes 
recommendations based on the existing renumbering mechanisms. 
According to the different stages, renumbering considerations are 
described in three categories: considerations and recommendations 
during network design, for the preparation of enterprise network 
renumbering, and during the renumbering operation. 


4. Managing Prefixes 


When renumbering an IPv6 enterprise site, the key procedural issue is 
switching the old prefix(es) to a new one(s). A new short prefix may 
be divided into longer ones for subnets, so we need to carefully 
manage the prefixes to ensure they are synchronized and coordinated 
within the whole network. 


4.1. Prefix Delegation 


For big enterprises, the new short prefix(es) usually comes down 
through offline human communication. But, for the SOHO-style (Small 
Office, Home Office) SMEs (Small & Medium Enterprises), the prefixes 
might be dynamically received by DHCPv6 servers or routers inside the 
enterprise networks. The short prefix(es) could be automatically 
delegated through DHCPv6-PD. Then the downlink DHCPv6 servers or 
routers could begin advertising the longer prefixes to the subnets. 


The delegation routers might need to renumber themselves with the new 
delegated prefixes. So, there should be a mechanism to inform the 
routers to renumber themselves by delegated prefixes; there should 
also be a mechanism for the routers to derive addresses automatically 
based on the delegated prefixes. 
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4.2. Prefix Assignment 


When subnet routers receive the longer prefixes, they can advertise a 
prefix on a link to which hosts are connected. Host address 
configuration, rather than routers, is the primary concern for prefix 
assignment, which is described in Section 5.1. 


5. Address Configuration 
5.1. Host Address Configuration 


o SLAAC and DHCPv6 Interaction Problems 


Both DHCPv6 and Neighbor Discovery (ND) protocols have an IP 
address configuration function, which are suitable for different 
Scenarios. During renumbering, the SLAAC-configured hosts can 
reconfigure IP addresses by receiving ND Router Advertisement (RA) 
messages containing new prefix information. (It should be noted 
that the prefix delivery could be achieved through DHCPv6 
according to [PREFIX-DHCPv6]). The DHCPv6-configured hosts can 
reconfigure addresses by initiating RENEW sessions [RFC3315] when 
the current addresses' lease times are expired or when they 
receive reconfiguration messages initiated by the DHCPv6 servers. 


Sometimes the two address configuration modes may be available in 
the same network. This would add additional complexity for both 
the hosts and network management. 


With the flags defined in RA (ManagedFlag (M) indicating the 
DHCPv6 service available in the network; OtherConfigFlag (0) 
indicating other configurations such as DNS/routing), the two 
Separated address configuration modes are correlated. However, 
the ND protocol does not define the flags as prescriptive but only 
as advisory. This has led to variation in the behavior of hosts 
when interpreting the flags; different operating systems have 
followed different approaches. (For more details, please refer to 
[DHCPv6-SLAAC] and [6RENUM-SLAAC].) 


The impact of ambiguous M/O flags includes the following aspects: 


- DHCPv6-configured hosts might not be able to be renumbered by 
RA 


It is unclear whether a DHCPv6-configured host will accept 
address configuration though RA messages, especially when the M 
flag transitions from 1 to 0; this depends on the 
implementation of the operating system. It might not be 
possible for administrators to only use RA messages for 
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renumbering, since renumbering might fail on some already 
DHCPv6-configured hosts. This means administrators have to use 
DHCPv6 reconfiguration for some DHCPv6-configured hosts. It is 
not convenient, and DHCPv6 reconfiguration is not suitable for 
bulk usage as analyzed below. 


- DHCPv6-configured hosts might not be able to learn new RA 
prefixes 


[RFC5887] mentions that DHCPv6-configured hosts may want to 
learn about the upstream availability of new prefixes or loss 
of prior prefixes dynamically by deducing this from periodic RA 
messages. Relevant standards [RFC4862] [RFC3315] are ambiguous 
about what approach should be taken by a DHCPv6-configured host 
when it receives RA messages containing a new prefix. Current 
behavior depends on the operating system of the host and cannot 
be predicted or controlled by the network. 


- SLAAC-configured hosts might not be able to add a DHCPv6 
address (es) 


The behavior when the host receives RA messages with the M flag 
set is unspecified. 


The host may start a DHCPv6 session and receive the DHCPv6 

address configuration, or it may just ignore the messages. 

Whether the hosts start DHCPv6 configuration is outside the 
control of the network side. 


5.2. Router Address Configuration 
o Learning New Prefixes 


As described in [RFC5887], "if a site wanted to be multihomed 
using multiple provider-aggregated (PA) routing prefixes with one 
prefix per upstream provider, then the interior routers would need 
a mechanism to learn which upstream providers and prefixes were 
currently reachable (and valid). In this case, their Router 
Advertisement messages could be updated dynamically to only 
advertise currently valid routing prefixes to hosts. This would 
be significantly more complicated if the various provider prefixes 
were of different lengths or if the site had non-uniform subnet 
prefix lengths." 
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6. 


6. 


Liu, 


L. 


Restarting After Renumbering 


As [RFC2072] mentions, some routers cache IP addresses in some 
Situations, so routers might need to be restarted as a result of 
Site renumbering. While most modern systems support a cache-clear 
function that eliminates the need for restarts, there are always 
exceptions that must be taken into account. 


Router Naming 


[RFC4192] states that "To better support renumbering, switches and 
routers should use domain names for configuration wherever 
appropriate, and they should resolve those names using the DNS 
when the lifetime on the name expires". As [RFC5887] described, 
this capability is not new, and currently it is present in most 
IPsec VPN implementations. However, many administrators may need 
to be alerted to the fact that it can be utilized to avoid manual 
modification during renumbering. 


Updating Address-Relevant Entries 


In conjunction with renumbering the nodes, any configuration or data 
store containing previous addresses must be updated as well. Some 
examples include DNS records and filters in various entities such as 
Access Control Lists (ACLs) in firewalls/gateways. 


DNS Records Update 
Secure Dynamic DNS (DDNS) Update 


In real network operations, a DNS update is normally achieved by 
maintaining a DNS zone file and loading this file into the site's 
DNS server(s). Synchronization between host renumbering and the 
updating of its AAAA record is hard. [RFC5887] discusses an 
alternative that uses the Secure Dynamic DNS Update [RFC3007], in 
which a host informs its own DNS server when it receives a new 
address. 


The Secure Dynamic DNS Update has been widely supported by the 
major DNS implementations, but it hasn't been widely deployed. 
Normal hosts are not suitable to do the update, mainly because of 
the complex key-management issues inherited from secure DNS 
mechanisms, so current practices usually assign DHCP servers to 
act as DNS clients to request that the DNS server update relevant 
records [RFC4704]. The key-management problem is tractable in the 
case of updates for a limited number of servers, so Dynamic DNS 
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updates could serve as a suitable solution for keeping server DNS 
records up to date on a typical enterprise network. However, this 
solution is not easily applicable to hosts in general. 


To address the larger use case of arbitrary non-server hosts being 
renumbered, DHCP servers have to learn that the relevant hosts 
have changed their addresses and thus trigger the DDNS update. If 
the hosts were numbered and also renumbered by DHCP, it would be 
easy for the DHCP servers to learn the address changes; however, 
if the hosts were numbered by SLAAC, then there could be trouble. 


6.2.  In-Host Server Address Update 


While DNS stores the addresses of hosts in servers, hosts are also 
configured with the addresses of servers, such as DNS and RADIUS 
servers [RFC2865]. While renumbering, the hosts must update these 
addresses if the server addresses change. 


In principle, the addresses of DHCPv6 servers do not need to be 
updated since they could be dynamically discovered through 
DHCPv6-relevant multicast messages. But in practice, most relay 
agents have the option of being configured with a DHCPv6 server 
address rather than sending to a multicast address. Therefore, the 
DHCP server addresses update might be an issue in practice. 


6.3. Address Update in Scattered Configurations 


Besides the DNS records and the in-host server address entries, there 
are also many places in which IP addresses are configured, for 
example, filters such as ACL and routing policies. There are even 
more sophisticated cases where the IP addresses are used for deriving 
values, for example, using the unique portion of the loopback address 
to generate an ISIS net ID. 


In renumbering, updating the IP addresses in all the above mentioned 
places is burdensome and error-prone. We lack a "one-stop" mechanism 
to trigger the updates for all the subsystems on a host/server and 
all the external databases that refer to the IP address update. We 
break the general "one-stop" gap into the following two aspects. 


o Self-Contained Configuration in Individual Devices 


Ideally, IP addresses can be defined as a value once, and then the 
administrators can use either keywords or variables to call the 
value in other places such as a sort of internal inheritance in 
CLI (command line interface) or other local configurations. This 
makes it easier to manage a renumbering event by reducing the 
number of places where a device's configuration must be updated. 
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However, it still means that every device needs to be individually 
updated, but only once instead of having to inspect the whole 
configuration to ensure that none of the separate places that a 
given IP address occurs is missed. 


Among current devices, some routers support defining multiple 
loopback interfaces that can be called in other configurations. 
For example, when defining a tunnel, it can call the defined 
loopback interface to use its address as the local address of the 
tunnel. This can be considered as a kind of parameterized self- 
contained configuration. However, this only applies to certain 
use Cases; it is impossible to use the loopback interfaces to 
represent external devices, and it is not always possible to call 
loopback interfaces in other configurations.  Parameterized self- 
contained configuration is still a gap that needs to be filled. 


o Unified Configuration Management among Devices 


This refers to a more formalized central configuration management 
System, where all changes are made in one place, and the system 
manages how changes are pushed to the individual devices. This 
issue contains two aspects, as follows: 


- Configuration Aggregation 


Configuration data based on addresses or prefixes are usually 
Spread out in various devices. As [RFC5887] describes, some 
address configuration data might be widely dispersed and much 
harder to find. Some will inevitably be found only after the 
renumbering event. Because there's a big gap in configuration 
aggregation, it is hard to get all the relevant configuration 
data together in one place. 


- Configuration Update Automation 


As mentioned in Section 3.2, [LEROY] proposes a mechanism that 
can automatically update the configurations. The mechanism 
utilizes macros suitable for various devices such as routers 
and firewalls to update configurations based on the new prefix. 
Such an automation tool is valuable for renumbering because it 
can reduce manual operation, which is error-prone and 
inefficient. 


Besides the macros, [LEROY] also proposes the use of SOAP to 
deliver the macros to the devices. Along with SOAP, we may 
consider whether it is possible and suitable to use other 
standardized protocols, such as the Network Configuration 
Protocol (NETCONF) [RFC6241]. 
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7. 


In current real networks, most devices use vendor-private 
protocols to update configurations, so it is not necessarily 
valid to assume that there is going to be a formalized 
configuration management system to leverage. Although there 
are some vendor-independent tools as mentioned in Section 3.2, 
a standard and comprehensive way to uniformly update 
configurations in multi-vendor devices is still missing. 


Renumbering Event Management 


From the perspective of network management, renumbering is an event 
that may need additional processes to make it easier and more 
manageable. 


Pale 


Renumbering Notification 


The process of renumbering could benefit from hosts or servers being 
made aware of an occurrence of a renumbering event. Following are 
several examples of additional processes that may ease renumbering. 


o 


Liu, 


A notification mechanism may be needed to indicate to hosts that a 
renumbering event has changed some DNS records in DNS servers 
(normally, in an enterprise, it is a local recursive DNS 
server(s)), and then the hosts might want to refresh the DNS 
cache. That mechanism may also need to indicate that such a 
change will happen at a specific time in the future. 


As suggested in [RFC4192], if the DNS service can be given prior 
notice about a renumbering event, then delay in the transition to 
new IPv6 addresses could be reduced and thus improve the 
efficiency of renumbering. 


Router awareness: In a site with multiple domains that are 
connected by border routers, all border routers should be aware of 
renumbering in one domain or multiple domains and update the 
internal forwarding tables and the address-/prefix-based filters 
accordingly to correctly handle inbound packets. 


Ingress filtering: ISPs normally enable an ingress filter to drop 
packets with source addresses from other ISPs at the end-site 
routers to prevent IP spoofing [RFC2827]. In a multihomed site 
with multiple PA prefixes, the ingress router of ISP A should be 
notified if ISP B initiates a renumbering event in order to 
properly update its filters to permit the new legitimate 
prefix(es). For large enterprises, it might be practical to 
manage this new legitimate prefix information through human 
communication. However, for the millions of small enterprises, an 
automated notification mechanism is needed. 
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o Log collectors: In the NMS (network management system), log 
collectors that collect logs through syslog, SNMP notification, 
IPFIX, etc. usually treat the UDP message source IP addresses as 
the host or router IDs. When one source IP address is changed, 
the log collectors will consider that a new device appeared in the 
network. Therefore, a mechanism is needed for the NMS 
applications to learn the renumbering event including the mappings 
of old and new IP addresses for each host/router, so that they 
could update the address-relevant mappings as described in Section 
ES 


7.2. Synchronization Management 
o DNS Update Synchronization 


The DNS changes must be coordinated with node address 
configuration changes.  DNS has a latency issue of propagating 
information from the server to the resolver. The latency is 
mainly caused by the Time to Live (TTL) assigned to individual DNS 
records and the timing of updates from primary to secondary 
servers [RFC4192]. 


Ideally, during a renumbering operation, the DNS TTLs should 
always be shorter than any other lifetimes associated with an 
address. If the TTLs were set correctly, then the DNS latency 
could be well controlled. However, there might be some 
exceptional situations in which the DNS TTLs were already set too 
long for the time available to plan and execute a renumbering 
event. In these situations, there are currently no mechanisms to 
deal with the already configured long DNS TTLs. 


o NMS Address-Relevant Mapping Synchronization 


As described in Section 7.1, the NMS needs to learn the 
renumbering event and thus correlate the old and new address in 
the logs. If the NMS applies unique IDs for the hosts or routers, 
then the mappings between the unique IDs and IP addresses also 
need to be updated after renumbering. 


7.3.  Renumbering Monitoring 


While treating renumbering as a network event, mechanisms to monitor 
the renumbering process might be needed to inform the administrators 
whether the renumbering has been successful. Considering that the 
address configuration operation might be stateless (if ND is used for 
renumbering), it is difficult to monitor. 
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8. Miscellaneous 


Since multicast and mobility are special use Cases that might not be 
included in routine or common renumbering operations, they are 
discussed separately in this miscellaneous section. 


8.1. Multicast 


From the perspective of interface renumbering operations, renumbering 
a multicast address is the same as renumbering a unicast address. So 
this section mainly discusses the issues from the perspective of the 
impact to the multicast application systems caused by renumbering. 
Renumbering also has an impact on multicast.  Renumbering of unicast 
addresses affects multicast even if the multicast addresses are not 
changed. There may also be cases where the multicast addresses need 
to be renumbered. 


o Renumbering of Multicast Sources 


If a host that is a multicast source is renumbered, the 
application on the host may need to be restarted for it to 
successfully send packets with the new source address. 


For ASM (Any-Source Multicast), the impact on a receiver is that a 
new source appears to start sending and it no longer receives from 
the previous source. Whether this is an issue depends on the 
application, but we believe it is likely not to be a major issue. 


For SSM (Source-Specific Multicast) however, there is one 
significant problem. The receiver needs to learn which source 
addresses it must join. Some applications may provide their own 
method for learning sources, where the source application may 
somehow signal the receiver. 


Otherwise, the receiver may, for example, need to get new SDP 
(Session Description Protocol) information with the new source 
address. This is similar to the process for learning a new group 
address; see the "Renumbering of Multicast Addresses" topic below. 


o Renumbering of Rendezvous-Point 


If the unicast addresses of routers in a network are renumbered, 
then the RP (Rendezvous-Point) address is also likely to change 
for at least some groups. An RP address is needed by PIM-SM 
(Protocol Independent Multicast - Sparse Mode) to provide ASM and 
for Bidir PIM. Changing the RP address is not a major issue, 
except that the multicast service may be impacted while the new RP 
addresses are configured. If dynamic protocols are used to 
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distribute group-to-RP mappings, the change can be fairly quick 
and any impact time should be very brief. However, if routers are 
statically configured, the time impacted depends on how long it 
takes to update all the configurations. 


For PIM-SM, one typically switches to SPT (Shortest-Path-Tree) 
when the first packet is received by the last-hop routers. 
Forwarding on the SPT should not be impacted by the change of IP 
address. A network operator should be careful not to deprecate 
the previous mapping before configuring a new one, because 
implementations may revert to Dense Mode if no RP is configured. 


o Renumbering of Multicast Addresses 


In general, multicast addresses Can be chosen independently of the 
unicast addresses, and the multicast addresses can remain fixed 
even if the unicast addresses are renumbered. However, for IPv6, 
there are useful ways of deriving multicast addresses from unicast 
addresses, such as described in "Unicast-Prefix-based IPv6 
Multicast Addresses" [RFC3306] and "Embedded-RP IPv6 Multicast 
Addresses" [RFC3956]. In those cases, the multicast addresses 
used may have to be renumbered. 


Renumbering group addresses may be complicated. For multicast, it 
is common to use literal addresses and not DNS. When multicast 
addresses are changed, source applications need to be reconfigured 
and restarted. 


Multicast receivers need to learn the new group addresses to join. 


Note that for SSM, receivers need to learn which multicast 
channels to join. A channel is a source and group pair. This 
means that for an SSM application, a change of source address is 
likely to have the same effect as a change of group address. 


Some applications may have dynamic methods of learning which 
groups (and possibly sources) to join. If not, the application 


may have to be reconfigured and restarted. 


One common way for receivers to learn the necessary parameters is 


by use of SDP. SDP information may be distributed via various 
application protocols or from a file. An SDP file may be 
distributed via HTTP, email, etc. If a user is using a web 


browser and clicking on a link to launch the application with the 
necessary data, it may be a matter of closing the current 
application and re-clicking the link. 
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In summary, currently, multicast renumbering issues are basically 
handled by application-specific methods. There is no standard way 
to guarantee that multicast service could live across a 
renumbering event. 


8.2. Mobility 


As described in [RFC5887], if a mobile node's home address changes 
unexpectedly, the node can be informed of the new global routing 
prefix used at the home site through the Mobile Prefix Solicitation 
and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. However, 
if the mobile node is disconnected at the time of home address 
renumbering, it will no longer know a valid subnet anycast address 
for its home agent, leaving it to deduce a valid address on the basis 
of DNS information. 


So, for Mobile IP, we need a better mechanism to handle the change of 
home agent address while the mobile address is disconnected. 


9. Gap Summary 
The following is a summary of the gaps identified previously in this 
document that are considered solvable, but may require process or 
protocol changes to resolve. 


9.1. Managing Prefixes 


o A mechanism informing the routers to renumber themselves by 
delegated prefixes. 


o A mechanism for the routers to derive addresses automatically 
based on the delegated prefixes. 


9.2. Address Configuration 
o Host Address Configuration 


- DHCPv6-configured hosts might not be able to be renumbered by 
RA on some current implementations. 


- DHCPv6-configured hosts might not be able to learn new RA 
prefixes on some current implementations. 


- SLAAC-configured hosts might not be able to add DHCPv6 
address(es) on some current implementations. 
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o Router Address Configuration 


- A mechanism for interior routers in a multihomed site to learn 
which upstream providers and prefixes are currently reachable. 


- Cache-clear might need to restart (rarely in modern routers). 


- Use of router domain names is not widely learned or deployed by 
administrators. 


9.3.  Address-Relevant Entries Update 
o DNS Records Update 
- For key-management scalability issues, secure dynamic DNS 
update is usually done by DHCP servers on behalf of the hosts, 
So it might not be practical for SLAAC-configured hosts to do 
secure DDNS. 
o In-Host Server Address Update 
- DHCP relays might be configured with DHCP server addresses 
rather than by sending multicast messages to discover the DHCP 
server dynamically, so updating the DHCP server addresses might 
be an issue in practice. 
o Address Update in Scattered Configurations 
- For devices that don't support parameterized configuration, 
administrators need to individually update all devices in which 


IP addresses were previously configured. 


- It is hard to get all the address-relevant configurations 
Spread in various devices through one place. 


- Uniformly updating configurations in multi-vendor devices is 
currently a big gap that needs to be filled. 
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9.4. Renumbering Event Management 
o Renumbering Notification 


- A mechanism to indicate a host's local recursive DNS is going 
to be renumbered. 


- A prior notice about a renumbering event for DNS. 


- A mechanism for border routers to know internal partial 
renumbering. 


- For multihomed sites, a mechanism is needed to notify the 
egress router connecting to ISP A that the egress router 
connecting to ISP B has initiated renumbering. 

- A mechanism is needed for the NMS applications to learn the 
renumbering event, so that they could correlate the old and new 
addresses in the logs, and update the unique ID of the device 
and address mappings. 

o Synchronization Management 

- DNS information propagation latency issue. 

- Mechanisms are needed for the NMS applications to correlate the 
old and new addresses in logs and to update the unique ID of 
the device and address mappings. 


o Renumbering Monitoring 


- Mechanisms to monitor the process and feedback of renumbering 
might be needed. 


9.5. Miscellaneous 
o Multicast 


- A mechanism for SSM receivers to learn the source addresses 
when multicast sources are renumbered. 


o Mobility 


- A better mechanism to handle a change of home agent address 
while the mobile address is disconnected. 


Liu, et al. Informational [Page 19] 


RFC 7010 IPv6 Site Renumbering Gap Analysis September 2013 


10. Gaps Considered Unsolvable 


This section lists gaps that have been identified by other documents 
but are considered unsolvable. 


10.1. Address Configuration 
o RA Prefix Lifetime Limitation 


Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime 
is greater than 2 hours or greater than RemainingLifetime, set the 
valid lifetime of the corresponding address to the advertised 
Valid Lifetime." So when renumbering, if the previous 
RemainingLifetime is longer than two hours, it is impossible to 
reduce a prefix's lifetime to less than two hours. This 
limitation is to prevent denial-of-service attacks. 


10.2.  Address-Relevant Entries Update 
o DNS Authority 


In an enterprise that hosts servers on behalf of collaborators and 
customers, it is often the case that DNS zones outside the 
administrative control of the hosting enterprise maintain resource 
records concerning addresses for hosted nodes within its address 
space. When the hosting enterprise renumbers, it does not have 
sufficient authority to change those records. 


This is an operational and policy issue. It is out of scope for 
this document to consider a technical solution or to propose an 
additional protocol or mechanism to standardize the interaction 
between DNS systems for authority negotiations. 


o DNS Entries 


DNS entries commonly have matching reverse DNS entries that will 
also need to be updated during renumbering. It might not be 
possible to combine forward and reverse DNS entry updates in one 
procedure where addresses are not being managed using DHCP. 


o DNS Data Structure Optimization 


[RFC2874] proposed an A6 record type for DNS recording of the IPv6 
address and prefix. Several extensions to DNS query and 
processing were also proposed. A6 was designed to be a 
replacement for the AAAA record. The changes were designed to 
facilitate network renumbering and multihoming. With the A6 
record and the extensions, an IPv6 address could be defined by 
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10. 


11. 


Liu, 


using multiple DNS records. This feature would increase the 
complexity of resolvers but reduce the cost of zone file 
maintenance, so renumbering could be easier than with the AAAA 
record. 


[RFC2874] has been deprecated and moved to Historic status by 


[RFC6563]. The A6 record has not been widely used and has been 
shown to have various problems and disadvantages (see Section 2 in 
[RFC6563]). The idea of a structured record to separate prefix 


and suffix is still potentially valuable for renumbering, but 
avoiding the problems of the A6 record would require a major 
development effort. 


Miscellaneous 


For the transport layer, [RFC5887] said that TCP connections and 
UDP flows are rigidly bound to a given pair of IP addresses. 


For the application layer, in general, we can assert that any 
implementation is at risk from renumbering if it does not check 
whether an address is valid each time it starts session resumption 
(e.g., a laptop wakes from sleep state). It is also more or less 
risky when it opens a new communications session by using cached 
addresses. 


We considered the above two points (ID/Locator overloading in 
transport layer and address caching in application layer) fundamental 
issues that might not be proper to deal with just in terms of 
renumbering. 


Security Considerations 
Prefix Validation 


Prefixes from the ISP may need authentication to prevent prefix 
fraud.  Announcing changes of site prefix to other sites (for 
example, those that configure routers or VPNs to point to the site 
in question) also needs validation. 


In the LAN, Secure DHCPv6 [SECURE-DHCPv6] or Secure Neighbor 


Discovery (SEND) [RFC3971] deployment may be needed to validate 
prefixes. 
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o Influence on Security Controls 


During renumbering, security controls (e.g., ACLs) protecting 
legitimate resources should not be interrupted. For example, if 
some addresses are in a blacklist, they should not escape from the 
blacklist due to renumbering. 


Addresses in SEND certificates will need to get updated when 
renumbering. During the overlap between old and new addresses, 
both certificates must remain valid. 


o Security Protection for Renumbering Notification 


Section 7.1 mentions possible notification mechanisms to signal a 
change in the DNS system or in the border routers related to a 
renumbering event. Since the DNS system and border routers are 
key elements in any network, and they might take action according 
to the notification, a security authentication for the renumbering 
notification is needed. 


o Security Protection for Configuration Update 
Automated configuration update approaches like [LEROY] would 
increase the risk since a bad actor with the right permission 


could cause havoc to the networks. 
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